
La utilización de casos de prueba   en el desarrollo de software es una práctica ampliamente extendida. Como su propio nombre sugiere, un caso de prueba   es una herramienta para la comprobación del correcto funcionamiento de componentes software. 

Dentro de los paradigmas de pruebas de software podemos encontrar \emph{Black-Box Testing} y \emph{White-Box Testing}. 

\begin{itemize}
\item Black-Box Testing   es un método de pruebas de software que sigue el \emph{modelo de caja negra}, en el cual simplemente se dan unos datos de entrada a la aplicación y se obtienen unos resultados. En este método no es necesario conocer el código del programa para poder comprobar su funcionamiento, únicamente basta con conocer la respuesta que el programa debe proporcionar ante los datos sumistrados. Si la respuesta del programa es la esperada, entonces se considera que el caso de prueba es positivo, es decir, se cumplen los requisitos de funcionalidad. En otro caso, el caso de prueba   se dice que es negativo.

\item White-Box Testing, o \emph{modelo de caja blanca}, es un método de pruebas de software en el cual, a diferencia de Black-Box Testing, se tiene una visibilidad completa del funcionamiento interno del programa, de su lógica y estructura. En este modelo se tiene acceso al código del programa, permitiendo realizar una comprobación más exhaustiva del mismo. La primera idea que puede plantearse es comprobar que todas y cada una de las posibles rutas que puede tomar la ejecución de un programa se comportan como se espera. Por ejemplo, suponiendo que nos encontramos un código escrito en un lenguaje tipo C, es muy habitual encontrarse con la siguiente situación:

\begin{verbatim}
if(condicion) {
    // cuerpo del if
} else {
    // cuerpo del else
}
\end{verbatim}

En este caso, la ejecución del código puede tomar dos rutas, dependiendo de si se cumple la condición de la sentencia \cod{if-else} o no. En caso de que la evaluación de la condición sea cierta, se ejecutará el código correspondiente al cuerpo de la sección \cod{if} de la sentencia. Por el contrario, si la evaluación de la condición resulta falsa, se ejecutará el cuerpo de la sección \cod{else} de la sentencia. Por tanto, utilizando el modelo de caja blanca para probar este código, se tienen dos casos de prueba bien diferenciados:

\begin{enumerate}
\item Uno que haga que la evaluación de la condición sea cierta, ejecutándose así la ruta del \cod{if}.
\item Otro que haga que el resultado de evaluar la condición sea falsa, por lo que se ejecutará la ruta del \cod{else}.
\end{enumerate}
\end{itemize}
Para una simple sentencia \cod{if-else} tenemos, al menos, dos casos de prueba. Sin embargo en sistemas software de carácter industrial o profesional, realizar un caso de prueba   para cada posible ruta que pueda tener la ejecución del código es una tarea muy costosa. Por ello, se utilizan  diversos \emph{criterios de recubrimiento}  \cite{Williams_2006} del código del programa. Estos criterios de recubrimiento   pueden ayudar, junto con otras técnicas de desarrollo de casos de prueba  (test de unidad, test de integración, etc), a la obtención de un conjunto de casos de prueba que cubra los casos más significativos. 
El hecho de disponer de un conjunto de casos de prueba significativos, en función del criterio de recubrimiento seguido, hace que dicho conjunto sea tratable. Por el contrario, obtener un conjunto de casos de prueba que cubra todas y cada de las posibles combinaciones de valores que pueden tomar las variables del programa, generalmente no es computable, pues nunca podemos estar seguros de haber recorrido todos los posibles caminos que puede tomar un programa general. Por ello, detectar los posibles puntos débiles de un sistema software puede ser de gran ayuda en la elección de los criterios de recubrimiento a utilizar.

En el caso particular de SQL, un buen recubrimiento consiste en transformar una consulta   SQL inicial en un conjunto de consultas independientes, de forma que cada una de estas consultas compruebe condiciones individuales de la consulta inicial \cite{Tuya:2010} (\emph{full predicate coverage} en la literatura). De esta forma, se puede obtener un conjunto de casos de prueba   para cada una de estas consulta. La unión de estos conjuntos forma un conjunto de casos de prueba para la consulta original.

Nuestro trabajo se centra en la generación de casos de prueba   a partir de un conjunto de tablas y de vistas SQL  y no realiza el proceso de transformación de la vista inicial en el conjunto de casos de prueba antes descrito, sin embargo, nuestro puede ser utilizado para encontrar dichos casos de prueba si se le proporcionan las vistas que realizan el recubrimiento mencionado.